In general, a database is any collection of information organized for rapid search and retrieval. A database stored in a computer-readable medium commonly is modeled as a collection of one or more tables. Each table, in turn, is modeled as a collection of one or more records (referred to commonly as a “row”), and each record as a collection of one or more fields (referred to commonly as a “column”).
Generally, three types of users interact with a database: database administrators (DBAs), database programmers, and end-users. Each type of user interacts with a database through database management systems (DBMS), which are sophisticated server programs that directly manipulate data within a database. Most modern DBMSs support a standard structured query language (SQL), through which a user can specify exactly what information a database should store or retrieve for the user.
A DBA is responsible primarily for managing the information in a database. A DBA determines what goes into the database, how the database is structured and how information in the database is accessed. A DBA also determines how the database is secured and how the integrity of the database is checked and maintained. The DBA also monitors the database performance.
In contrast, a database programmer is primarily responsible for creating computer programs through which end-users can manipulate and apply to the data in a database to accomplish a specific task. Such programs (referred to herein as “database applications”) interact with a database through a DBMS within the constraints that the DBA has established. Database applications often use SQL or some minor variation adapted for use in such programs.
For many years, database programmers have developed “client” database applications that interact directly with a DBMS server. In general, these database applications provide a user interface to the DBMS and implement an enterprise's business rules for a particular application, such as entering a customer's order for products. The enterprise data, though, remained relatively centralized and available to multiple clients through the DBMS. In recent years, this traditional “two-tier” client/server system has been displaced slowly by more sophisticated multi-tier client/server systems. In general, a multi-tier system places at least one intermediate component between the client and the server. These components are referred to commonly as “middleware.” Programmers often use multiple client/server tiers to separate and delegate particular programming tasks. In particular, one tier usually provides a user interface, while a second tier implements an enterprise's business rules. A third tier generally implements the underlying data processing (such as creating a data structure to represent a customer's order in a database).
Regardless of architecture, though, most database applications frequently insert, modify, or delete data in the tables of a database. A history of these actions is often useful to administrators, auditors, and other analysts within an enterprise. Thus, many database applications record such actions in a log. A log may take many forms, but the most common include a separate table within the database itself and simple text files stored in the file systems somewhere. Although distinct database applications may share a single log, each database application generally is responsible for implanting a process for recording its own changes in the log. Consequently, each database programmer must write code that processes and records table changes in a log.
Of course, not only is it useful to record the history of changes to a database, but it is also sometimes useful to record the user that caused the changes and the time at which the changes occurred. In order to identify the user and time, database applications usually insert the user name and timestamp into each action.
The practical applications for change logs abound, as exemplified in U.S. Pat. No. 6,321,236 (the '236 patent). The '236 patent discloses a technique for storing table differences that are used to make client copies of a particular database table current. A client receives a client copy of a table having a version identifier. Later, the client requests synchronization of the client copy with the original database table on the server. The version identifier of the client copy of the database engine is accessed and all intervening updates are translated into instructions that are understood by the type of database engine run on the client system.
U.S. Pat. No. 6,631,374 (the '374 patent) also discloses a system in which changes to a database are important. Specifically, the '374 patent discloses a system and method for temporarily accessing data values in a database as of a requested query time. Whenever a transaction makes a change to a relative database block, the database engine creates an interested transaction entry, which is stored in the relative database block. A record of database operations is kept that includes transactions effecting row data changes.
Finally, United States application 2003/0212647 (the '647 application) discloses a method and system for maintaining a change history for a database design. More particularly, the '647 application allows change history data corresponding to a database design change to be automatically transmitted to the changed database.
While the concept of database change logs is not new, there currently is no convenient mechanism for centrally recording and managing such information. As already noted, database programmers must implement change log management in every conventional database application in which such information is desired. Clearly, any system that could eliminate this redundant and time consuming programming effort would have an immediate impact on development and administration costs, and contribute significantly to the advancement of this technical field. Those skilled in this art should appreciate the utility of the following detailed description of a novel system that addresses this need.